Mirroring functions include functions such as IBM's DS8000 PPRC (Peer-to-Peer Remote Copy), IBM's DS4000 Enhanced Remote Mirroring, application initiated mirroring like IBM's TSM (Tivoli Storage Manager) Mirroring, software based mirroring such as AIX LVM (Logical Volume Manager) Mirroring, eRDF (Embedded Resource Description Framework), EMC's SRDF, Network Appliance's SnapMirror, and IBM's GDPS (Geographically Dispersed Parallel Sysplex).
FIG. 1 represents a mirrored storage system 106, according to the state of the art. Therewith, the data of an application 102 is written to a first storage system 108 via a network 104 and then mirrored to a second storage system 110, usually via a separate mirror link 112, which may be part of the network 104 or which may be in a separate mirror network (not shown). The first storage system 108 is also denoted as primary system, while the second storage system 110 is denoted as secondary system. The storage systems 108, 110 are collectively called the mirrored storage system 106. A mirrored storage system may comprise more than two storage systems interconnected by one or more mirror links. Typically, there are one or more logical mirror pairs 114, 116 which are usually logical drives or LUNs being mirrored. One logical drive of a mirror pair resides in first storage system 108 and the second logical drive resides in second storage system 110. Thereby, one logical mirror pair 114 or 116 has a mirrored relationship.
One important requirement of data mirroring is the Recovery Point Objective (RPO) which determines the maximum delay tolerated for writing to the secondary system and which is usually expressed in minutes. Thus, the RPO describes the grade of identity between the data stored in the primary system 108, on the one hand, and the mirrored data in the secondary system 110, on the other hand. According to prior art, the RPO for a given system is fixed and cannot be adapted dynamically to the requirements of the applications writing to the mirrored storage system. This means the RPO is usually preconfigured by the system architecture and cannot be changed dynamically.
There may be more than one application 102 accessing one mirrored storage system. The RPO may not be equal for all applications accessing a storage system and may not be equal for a given application at any time. In addition, the RPO for one application may be different for particular periods of the day. In order to provide high availability during certain times of the day, an application may tolerate a RPO of 60 up to 120 minutes, for instance during production times when the data is deployed. This means that the storage system is available to the application even though the mirroring relationship or link does not work for 60 up to 120 minutes. During other times of the day, for example when data is written to the storage system, the RPO of an application may be 0 minutes to provide maximum data protection. This means that the mirroring relationship and link 112 are not allowed to be offline.
In addition, there are conflicting goals between high availability and disaster protection. While high availability is focused on instant access to data, disaster protection is focused on protecting the data. More precise, if the mirroring link or relationship fails, high availability requires the system to keep accepting write commands (RPO>0). Conversely, disaster protection requires the system to not accept any write commands because this will cause data inconsistencies between the two mirrored systems (RPO=0). Usually, these two requirements are not present at the same instant in time.